ftp.cs.arizona.edu/ftp.cs.arizona.edu.tar/ftp.cs.arizona.edu/icon/newsgrp/group02b.txt/000017_icon-group-sender_Mon Aug 19 13:09:36 2002.msg

Internet Message Format | 2003-01-02 | 6KB

Return-Path: <icon-group-sender>
Received: (from root@localhost)
    by baskerville.CS.Arizona.EDU (8.11.1/8.11.1) id g7JK9Xs14419
    for icon-group-addresses; Mon, 19 Aug 2002 13:09:33 -0700 (MST)
Message-Id: <[e-mail]>
From: [e-mail] (Gene Kahn)
X-Newsgroups: comp.lang.icon
Subject: Re: What about "Expressions?" (was Re: Icon Wish List)
Date: 18 Aug 2002 10:03:32 -0700
X-Complaints-To: [e-mail]
To: [e-mail]
Errors-To: [e-mail]
Status: RO

Reply to Steve, Jesse, Christopher, and Hrvoje:

The sentences

The mouse the cat the dog the man kicked chased bit died.
The horse raced past the barn collapsed.

are standard sentences in  introductory linguistics course that
illustrate one point or another. Steve and Jesse's interpretation is
the "generally accepted" reading:

The horse raced past the barn collapsed.
= The horse (which was) raced past the barn collapsed.

Jesse's grandfather's reading (see below), as he pointed out, is
incorrect or very marginal to most speakers. Most speakers don't
delete "which" in that context.

The horse raced past the barn collapsed
?= The horse (which) raced past the barn collapsed.

Setting off the the embedded clause with commas makes the sentence
easy to read, but this sentence differs from the original in
restrictiveness.

The horse, raced past the barn, collapsed.
<> The horse raced past the barn collapsed.

How did we get into a discussion of English grammar? Well, for one
thing, one's ability to write grammatical English is a requisite to
writing computer programs (in a revolutionary approach to
programming), as someone suggested earlier. So I was testing if those
I'm holding a discussion with are good programmers or not ;-). Also,
these sentences illustrate that certain structures even in natural
languages are harder to read than others. Headleass clause is one (the
sentence about the horse), embedding is another (the sentence about
the mouse), though, as Jesse pointed out, right-branching is easier to
read:

ML-like
The man kicked the dog
which chased the cat
which bit the mouse
which died.

and that's because essentially this has the effect of compounding
(concatenation).

It is not the plethora of parentheses that makes Lisp less readable to
me. It is the fact that it allows left- AND center- AND
right-branching (though indentation helps somewhat to clarify visually
the branches) PLUS deep nesting.

Left-branching
(+ (- (...)))

Center-branching
(+ (* a (...) b) c)

Right-branching
(+ a (* b (...)))

In concatenative languages (ML, Joy, etc.) , this would look like the
following, which, at this level would has a simple sequential
structure.

e1 . e2 . (...) . e3 . e4

Nesting is unavoidable in a language that eschews variables and
assignments, and to the programmer/writer the lure of deep nesting is
hard to resist. This poses readability problems to the next programmer
who has to maintain the code. (In my case, the comfort level is
roughly two nestings and three variables, which make for 5 items,
which is the lower bound of the magic number 7 plus or minus 2).
Though, as has been pointed out, one can choose to go against the
functional spirit of Lisp and use "let".

Now, you wouldn't want to say to someone "The mouse the cat the dog
the man kicked chased bit died" even if you know that it is
grammatical. So why would a programmer write in Lisp something like (+
(* a (...) b ) c )? Well, because the language was designed to
communicate with the compiler, and there is a heavy penalty if you
don't treat this feature as rule number one. So why don't programming
language designers think of designing an "artificial human" language
for describing objects and their behavior primarily for human
communication (but optimized under the hood for the compiler).

All this is getting to be out of topic. So back to the topic of the
original thread: wish list. Wish list to make Icon more useful. For
what tasks? For mainstream programming? Does Icon aspire to become a
mainstream language?

Genghis Khan's Conclusion:
If a language has not reached the mainstream within 9 years of Release
1.0, it never will.

I think that there is now nothing that proponents of Icon, Lisp,
Scheme, Eiffel, Smalltalk, and a host of other languages can do to
make their languages more mainstream (that is to say, as popularly
used as C++, Java, and Visual Basic). They will remain 'niche'
languages. This does not mean one should stop working on the language.
I'd say make Icon the best language at what it does best
(goal-directed processing), and make it a callable engine from
mainstream languages, and make it ridiculously easy to use libraries
and packages from other languages.

I'm off to the Scheme camp to check out what they have to offer ...

--gk


Jesse Tov <[e-mail]> wrote in message news:<[e-mail]>...
> Christopher Browne <[e-mail]>:
> > (LET* ((A 1)
> >        (B (* A 2)))
> >    (+ A B))
> >
> > which expands to
> > (let ((a 1))
> >    (let ((b (* a 2)))
> >       (+ a b)))
>
> So the same as scheme.
>
> >>    The horse which raced past the barn collapsed.
> >> When I hear it like this, it's ungrammatical to me.
> >
> > The problem here isn't grammar; it's semantics, and semantics that
> > don't make sense.
>
> I disagree---the semantics are fine if "collapsed" is a verb:
>
>    The horse collapsed.  Which horse collapsed?  The horse raced past
>    the barn collapsed.
>
> It's syntactically ambiguous, and with your parsing, the problem is
> semantics, but with my parsing the semantics are fine.
>
> > If we changed the last word from "collapsed" to "upright", it would
> > read:
> >    The horse raced past the barn upright.
>
> "Upright" just removes the ambiguity because it has to parse as an
> adjective, and and the syntax tree in which it works (your parsing
> above, but not mine) makes sense semantically.
>
> Jesse